Portal Client: Improve node status log #3327
Conversation
portal/network/portal_node.nim
Outdated
| radius = n.contentDB.dataRadius | ||
| radiusPercentage = radius div (UInt256.high() div u256(100)) | ||
| logRadius = logDistance(radius, u256(0)) | ||
| logRadiusPercentage = (logRadius * 100) div 256 |
There was a problem hiding this comment.
While I agree that showing the rounded down 0% is not very useful (hence also the original float precision TODO above), I do not think that showing the log radius percentage is any more useful to an user at all. Regular users have to understand log distance to know what this means, and even then, expressing it as a percentage is not so intuitive I think.
And for devs, I think the logRadius is handy, but from that you can deduct quite immediately the rest and do not need logRadiusPercentage.
There was a problem hiding this comment.
While I agree that showing the rounded down 0% is not very useful (hence also the original float precision TODO above), I do not think that showing the log radius percentage is any more useful to an user at all. Regular users have to understand log distance to know what this means, and even then, expressing it as a percentage is not so intuitive I think. And for devs, I think the logRadius is handy, but from that you can deduct quite immediately the rest and do not need
logRadiusPercentage.
After thinking about this a bit more I generally agree. Unfortunately, showing the U256 number as a float isn't currently supported by our libraries and I didn't find an easy solution. Even if we get it working, the decimals may be very small because we will eventually end up having very large amount of data in portal network. I think we should show the logRadius like this: radius / 256. Perhaps it could be named different to logRadius or perhaps it could go in a separate debug log since its not ideal for end users. My thoughts are that it doesn't matter too much and would be useful to just see the logRadius here.
There was a problem hiding this comment.
I've now removed the logRadiusPercentage field and moved the logRadius field to the last position which should be the least visible. Now that I think about it the existing radius field is not very useful for an end user either (not suggesting we remove it though) and I noticed that in the help when we set the radius using the static option we set it using a log radius value. See from the help:
--radius Radius configuration for the portal node. Radius can be either `dynamic` where
the node adjusts the radius based on `storage-size` option, or
`static:<logRadius>` where the node has a hardcoded logarithmic radius value.
Warning: `static:<logRadius>` disables `storage-size` limits and makes the node
store a fraction of the network based on set radius. [=Dynamic].
So considering that logRadius is an end user setting on the CLI perhaps its ok to be in the logs.
There was a problem hiding this comment.
Yes, I'm perfectly fine with having logRadius in there.
I noticed that in the Nimbus Portal fleet logs the Portal node status looks like this for the 2GB nodes:
And like this for the 35G nodes:
Using the default storage size of 2G the
radiusPercentageshows as 0%. This isn't very useful information for the user and the radius is actually likely to get smaller as the amount of data in the network grows.To improve the logs I suggest we use log radius and log radius percent which will be a better way to represent the information. We could either show both the
radiusPercentageandlogRadiusPercentageor just show the log radius named as radiusPercentage (log base 2).Also now showing the storage in MB instead of KB.
The updated log looks like this:
Alternatively we could show something like: